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operating  system  and  language  translators  are  identified. 
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I.   INTRODUCTION 

Dynamic  linking  orovi^es  a  flexible  and  convenient  way  tor  resolving  a 
orocedure's  symbolic  references  to  external  nrocedures  and  data.  Tt  is  dis- 
tinguished by  when  a  symbolic  reference  is  bound  to  the  (virtual)  address  of 
the  external  object,  viz. ,  bindinq  is  deferred  until  the  first  actual  refer- 
ence during  execution.  Yet  in  sqite  of  the  significant  benefits  and  more  than 
a  decade  to  assimilate  the  techno logy,  the  Multics  system  remains  as  essen- 
tially the  singular  working  examole.  Several  authors  of  articles  [1]  and 
ooerating  systems  texts  [2,31  imply  that  a  major  reason  tor  this  limited  use 
is  the  soecial  hardware  required.  We  have  addressed  this  limitation  and  have 
develooed  a  dynamic  linker  design  that  requires  no  more  hardware  sunoort  that 
is  orovided  by  modern  microcomouters. 

\.     background 

We  have  used  Multics  [41  as  the  standard  tor  the  dynamic  linking  capa- 
bilities we  would  like  to  orovide.  Multics  has  an  integrated  hardware  and 
software  design  with  the  hardware  features  that  strongly  supoort  dynamic  link- 
ing being  (1)  indirect  addressing  through  memory,  (2)  a  linkage  fault  during 
indirection,  (3)  segmentation,  and  (4)  demand  oaging. 

Mthough  commercial  microcomouters  do  not  have  the  range  of  hardware 
supoort  found  in  Multics,  they  are  increasingly  caoable.  This  has  naturally 
led  to  increased  exoectations  for  services,  and  extensive  caoabilities  such  as 
full-functioned  languages  (e.g.,  PL/I)  and  multinrogrammed,  multiorocessor 
ooerating  systems  [51  are  emerging.  We  believe  that  dynamic  linking  is  an 
attractive  addition  to  this  growing  set  of  system  caoabilities. 


H.     Objectives 

ve  want  our  desiqn  to  orovi^e  the  usual  benefits  of  dynamic  linking.  ^ 
orocess  should  include  onlv  those  orocedures  and  data  actually  referenced  dur- 
ing execution,  vice  those  included  in  the  oroqram.  Similarly,  during  software 
develooment  oroqrams  may  he  run  with  references  to  orocedures  (e.g.  ,  error 
routines)  not  yet  coded.  ^Iven  when  all  the  referenced  objects  are  available, 
thev  should  be  allocated  (memory)  resources  only  if  the  object  is  actuallv 
used,  without  the  user  predicting  the  actual  usage  before  oroqram  execution. 

The  dynamic  lin'<er  nust  not  seriouslv  deqrade  other  capabilities  of  the 
system.  We  have  ta'<en  care  to  accorrnodate  (but  not  require)  in-core  sharing 
of  (oure)  orocedures  and  data,  mixed  languaqes  in  a  orocess,  a  flexible  file 
system,  and  a  security  kernel  structure  r SI  for  the  ooeratinq  system.  °ro- 
qramminq  qenerality  is  oreserved  in  that  a  (dynamically  linked)  external 
reference  can  be  used  whenever  an  internal  reference  can  be  used. 

finally,  we  note  that  oertormance  has  been  a  dominant  consideration.  If 
all  oroqrams  were  interpreted  rather  than  translated  we  clearly  could  simulate 
the  Multics  hardware  suooort  for  dynamic  linkinq;  however,  for  reasons  of  oer- 
formance  we  have  not  chosen  the  interpreter  aooroach.  Our  major  oertormance 
objective  has  been  to  reduce  to  an  absolute  minimum  the  orocessinq  overhead 
required  tor  the  second  and  subsequent  references  to  an  external  object.  Much 
more  orocessinq  is  required  tor  the  first  reference  that  must,  of  course, 
create  and  save  (tor  subsequent  references)  the  information  on  the  bindinq 
from  symbolic  reference  to  virtual  address.  The  comoletion  of  this  first 
reference  is  at  the  heart  of  dynamic  linkinq. 


II.   B^SIC  CONCEPTS  FOR  DYNAMIC  LIMKIMO 

Dynamic  lin'<inq  always  occurs  durinq  the  execution  ot  a  Procedure  in  the 
address  inace  ot  a  orocess.  It  results  from  the  symbolic  reference  to  an 
(explicitly  declared)  external  orocedure  or  data  object.  Oynanic  lin'<inq 
implicitly  requires  the  notion  of  a  seqment,  i.e.,  a  loqical  qroun  ot  intorma- 
tion  (external  object)  that  retains  distinct  attributes  (e.q.  ,  symbolic  name) 
tor  the  life  of  the  process.  Mthouqh  hardware  seqmentation  is  not  mandated, 
each  seqment  has  an  identifier  (unique  in  each  process)  that  we  will  call  the 
seqment  number.  >\  seqnent  number  and  an  offset  within  the  seqment  constitute 
a  virtual  address  that  can  be  used  to  reference  a  soecific  location. 

On  a  orocedure's  first  reference  (in  a  orocess)  to  an  external  object 
the  dynamic  linker,  with  suoport  from  the  ooeratinq  system,  computes  the  vir- 
tual address  corresoondinq  to  the  symbolic  reference.  The  linker  stores  this 
bindinq  in  what  we  call  a  link.  We  then  say  the  link  is  ''snaooed",  and  subse- 
quent references  are  made  throuqh  this  snaooed  link  without  use  of  the  linker. 
We  will  next  examine  conceotually  the  functions  and  data  bases  that  make  uo 
the  linker,  and  the  rationale  for  them. 

r 

\.     External  Drocedures 

Consider  what  haooens  when  a  orocedure  seqment  <Caller>  executes  the 
first  reference  in  a  process  corresnondinq  to  the  source  statement: 
CALL  Tarqet 

<Caller>'s  object  code  is  tyoically  envisioned  as  containing: 
CALL  (virtual  address  ot  the  entry  into  <Target>)     (I) 

at  the  time  ot  execution.  However,  until  <Tarqet>  is  linked  this  is  not 


feasible,  since  its  virtual  address  is  not  known.  We  miqht  alternatively  con- 
sider translatinq  the  source  into 

CALL  <Linker>  ("Target")  (?) 

where  <Lin'<er>  is  a  Procedure  sequent  that  calls  on  the  underlying  omeratinq 
system  to  find  the  virtual  address  ot  the  entry  tor  the  sequent  named  "Tar- 
get". 

\tter  determining  the  virtual  address  ot  <Tarqet> ,  the  linker  could 
"snao  the  link"  by  overwriting  statement  (?)  in  <Caller>'s  object  co^.q  with 
statement  (1) ,  a  call  to  the  <Target>.  This  is  essentiallv  what  is  done  in 
the  traditional  (static)  linking  loader  [11.  'lowever,  to  do  this  dynamicallv 
tor  a  runninq  urogram  makes  <Caller>  immure,  in  violation  ot  our  desiqn  cri- 
teria. To  address  this  we  tollow  the  Multics  [4]  examoie,  introducinq  the 
concept  ot  a  linkage  segment  and  a  linkage  oointer  that  ooints  to  the  section 
(linkage  table)  in  it  tor  <Caller>. 

^very  Process  has  a  distinct  (never  shared)  linkaqe  table  which  contains 
an  outqoinq  link  tor  each  external  reference  bv  <Caller>.  The  outqoinq  link 
tor  the  reference  to  <Tarqet>  can  he  at  a  fixed  ottset  (at  translation)  from 
the  linkaqe  oointer.  Thus  the  object  code  ot  the  mure  Procedure  <qaller>  can 
be  ot  the  form: 

CV.L  (Linkaqe_oo inter  +  <Tarqet>  link  offset)        (3) 

The  outqoinq  link  is  desiqned  to  invoke  <Linker>  on  the  first  reference  with 
somethinq  similar  to  statement  (I)  above,  ^he  linker  then  modifies  (i.e., 
snaos)  the  outgoing  link  to  invoke  <Tarqet*>  on  subsequent  references. 

It  miqht  seem  that  the  snaooed  link  should  mereiv  be  ot  the  form  of 
statement  (?)  above.  'lowever,  a  significant  oroblem  arises,  Miter  the 
transfer  ot  control  to  <Target>  we,  ot  course,  exoect  the  linkage  oointer  to 


ooirtt  to  the  linkage  table  tor  <Tarqet>,  not  <Caller>.  'Jntortunately,  the 

(oure)  code  of  <Tarqet>  cannot  orooerly  load  the  linkaqe  oointer,  because  the 

aoorooriate  virtual  address  is  unknown  at  translation  time.  Therefore,  the 

linker  includes  in  the  linkaqe  table  ot  <Tarqet>  an  inconinq  link  tor  the 
entrv  to  <Tarqet>.  Thus  the  oroner  torn  tor  the  outqoinq  link  trom  <Caller> 
is: 

CALL  (<Tarqet>  incominq  link)  (4) 

This  snaooed  inconinq  link  contains  a  statement  to  load  the  linkaqe  pointer, 
tollowed  by  the  form  ot  statement  (I)  to  invoke  <Tarqet>.  This  comoletes  the 
invocation  and  dynamic  linkinq  ot  the  external  orocedure  <Tarqet>. 

B.  External  Oata 

\n   external  data  reference  has  many  similarities  to  the  above.  Consider 
the  reference  in  <Caller>  correspondinq  to  the  source  statement: 
do inter  :=  AOOR^SS (Oata) 

The  pure  code  in  <Caller>  will  be  very  similar  to  statement  (3)  for  the  same 
reasons;  in  oarticular  we  exoect  the  torm: 

CALL  (Linkaqe_Do inter  +  <Data>  link  ottset)         (5) 

The  unsnaoDed  link  in  <Caller>'s  linkaqe  table  will  be  similar  to  state- 
ment (2)  tor  Drocedures.  In  oarticular  the  torm 

CALL  <Linker>  ("'Data")  (^) 

will  invoke  the  linker  to  obtain  the  virtual  address  ot  <Data>  and  snaD  the 
link.  The  snapoed  link  is  much  simoler  than  tor  Drocedures.  We  need  some- 
thinq  ot  the  form: 

RETURN  (virtual  address  ot  <Oata»  (7) 


This  comoletes  the  reference  to  and  dynamic  linkinq  ot  the  external  data  seg- 
ment. 

ITT.  TV,  MicTxry^P'JT^  oYNvno  lw^  n^sio-N 

\.     The  Steos  in  Cstabiishinq  a  Link 

Havinq  examined  the  basic  concents  ot  a  dynamic  linker,  we  will  now 
investigate  the  features  ot  a  desiqn  tor  its  realization.  Once  aqain  the 
stens  (piqure  I)  necessary  to  dynamically  lin'<  some  external  orocedure  <Tar- 
net!  entrv_name>  (1)  to  orocedure  <Caller>  will  be  followed,  but  emphasis  will 
be  olaced  on  desiqn  details  vice  lin'<inq  concents. 

I.   Invokinq  the  Linker 

When  <Caller>'s  source  code  is  translated,  any  external  reference  to 
<Tarqet>  will  be  translated  into  code  which  transfers  the  execution  noint  to 
an  outqoinq  link  in  <Caller>'s  linkaqe  table  (Caller. link) .  Translated  code 
will  vary  from  system  to  system;  however,  conceotually  we  desire  to  have  a 
nure  orocedure  KCaller^'s  object  code)  call  some  imoure  nrocedure 
(Caller. link) .  This  will  allow  us  at  some  later  ooint  in  the  linkinq  nrocess 
to  convert  the  initialized  outqoinq  link  in  Caller. link  from  code  which 
invokes  the  linker  to  code  which  will  result  in  the  invocation  of  <Tarqetl 
entry_name>. 

we  have  mentioned  that  the  outqoinq  link  is  initialized  to  invoke  the 
linker.   One  method  to  do  this  would  be  for  the  outqoinq  link  to  oroduce  a 


(1)  Sntry_name  reoresents  a  label  within  <Tarqet>  which  can  be  referenced  bv 
an  external  orocedure.  ^n  entry  ooint  is  an  offset  within  <Tarqst>  associated 
with  some  entry  name. 
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hardware  fault  which  will  invoke  the  linger  as  a  fault  handler.  (This 
represents  the  most  qeneral  of  the  methods  available  and  is  the  method  used  in 
'•lultics.)  However,  barrinq  this  caoability,  the  linker  mav  be  invoked  via  a 
direct  jumo  in  the  outqoinq  link.  In  both  these  nethods  the  linker  would  be 
oassed  the  offset  ot"  the  svmbolic  name  <Tarqetl  entrv_name>  in  <qaller>'s  svm- 
bolic  name  table  (Caller. sym) .  (*\n  object's  svmbolic  name  table  stores  the 
symbolic  names  of  all  external  references  in  a  orocedure.  \dditionally  it 
will  be  used  to  retain  entrv  names  and  their  associated  entry  ooints  utilized 
within  the  orocedure.)  '\  third  mechanism  to  invoke  the  linker  is  via  an 
exolicit  call  in  <Cailer>'s  source  code  oassinq  to  the  linker  the  symbolic 
name  of  the  object  to  be  linked  as  a  actual  oarameter.  (This  represents  a 
soecial  case  which  will  be  discussed  later.) 

?.  Snaooinq  the  Link 

The  question  naturally  arises  of  how  the  linker  knows  where  Caller. svm 
is  located.  We  have  orovided  a  mechanism  to  resolve  this  oroblem  bv  olacinq 
the  virtual  address  ot  an  object's  svmbolic  name  table  in  a  header  in  the 
object's  linkaqe  table.  (We  can  always  find  an  object's  linkaqe  table  since 
we  orooose  to  store  a  oointer  to  it  in  a  linkaqe  address  table.)  Thus  the 
linker  can  access  the  <Tarqetl  entry_name>  by  utilizinq  the  virtual  address  of 
the  svmbolic  name  table  (from  the  linkaqe  table  header)  and  the  offset  it  was 
oassed  as  a  formal  oarameter. 

The  linker  will  then  oass  the  symbolic  name  <Tarqet>  to  a  module  in  the 
suoervisor  called  the  address  soace  manaqer  (which  will  be  discussed  in  more 
detail  later) .  \t  this  ooint  we  will  consider  the  address  soace  manaqer  a 
routine  which,  when  oassed  a  svmbolic  name,  enters  the  object  associated  with 
that  svmbolic  name  in  the  address  soace  ot  the  executinq  orocess  and  returns 


to  the  lin'<er  the  segment  number  assigned  to  that  object. 

Mow  that  we  know  the  segment  number  ot  <Target>,  we  can  generate  a  com- 
olete  virtual  address  tor  <Targetl  entry_name>  by  accessing  the  entry  Doint 
into  <Target>  associated  with  'entrv__name' .  Recall  that  the  symbolic  name 
table  ot  an  object  contains  not  only  the  symbolic  names  ot  external  refer- 
ences, but  also  entry  names  (and  their  associated  entry  points)  into  the 
object.  Thus  it"  we  can  access  Target. sym  we  can  find  the  entry  noint  associ- 
ated with  'entryjvame'.  When  the  segment  number  of  <Target>  is  returned  to 
the  linker,  the  linker  will  construct  a  linkage  table  for  <Target>  (if  one 
does  not  already  exist)  to  allow  <Target>  to  engage  in  dynamic  linking.  Since 
the  header  of  Target. link  contains  the  virtual  address  ot"  Target. sym,  we  can 
find  the  entry  noint  corresponding  to  'entry_name' . 

We  now  have  a  virtual  address  (of  the  form  <segment  number  I 
entry_point»  and  could  invoke  <Target|  entry_name>  at  this  ooint.  However, 
we  would  like  to  retain  this  virtual  address  to  simolify  subsequent  invoca- 
tions ot  <Targetl  entry_name>.  T*te  can  accomplish  this  goal  bv  storing  the 
virtual  address  ot"  <Targetl  entrv_nane>  in  Target. link.  \n  incoming  link  has 
been  set  aside  tor  this  purpose  and  we  can  transfer  control  to  this  incoming 
link  on  subsequent  calls  by  reolacing  the  jump  to  the  linker  found  in  the  out- 
going link  (in  Caller. link)  with  a  jumo  to  the  incoming  link  (for  <Targetl 
entry_name» .  Thus  subsequent  calls  will  follow  the  sequence  shown  in  ^igure 
2. 

Recall  that  the  linkage  nointer  is  used  to  indicate  the  start  of  the 
currently  executing  orocedure's  linkage  table.  Thus  when  we  start  executing 
in  <Target>,  we  want  the  linkage  oointer  to  point  to  Target. link.  The  incom- 
ing link  for  <Targetl  entry_name>  will  be  used  to  set  the  linkage  oointer 
(nrior  to  transferring  control  to  <Targetl  entry_name»  .   This  implies  that 
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when  <Caller>  calls  an  outgoing  link  the  linkage  oointer  (which  ooints  to 
Caller. link)  must  be  saved  and  furthemore  must  be  restored  when  the  orocess 
execution  ooint  returns  from  <Target>  to  <Caller>.  This  may  be  done  automati- 
cally by  the  hardware  C.\LL/RETTJRNI  sequence  or  exolicitly  by  the  object  code  in 
<Caller^. 

3.  Linking  Data 

The  steos  to  link  data  differ  slightly  from  those  for  linking  oro- 
cedures.  Fundamentally,  data  is  not  executed  and  does  not,  therefore,  have 
the  caoabiiity  to  initiate  dynamic  linking.  Thus  it  <Caller>  were  to  refer- 
ence some  data  object,  Oatal  entry_nane> ,  instead  of  invoking  <Hata|  entry- 
name>  all  we  really  want  to  know  is  its  virtual  address.  We  therefore  prooose 
that  when  snaooed,  the  outgoing  link  for  <Oata|  entry_name>  will  load  some 
oointer  register  with  the  virtual  address  of  <Oata|  entry_name>  and  then 
return  to  <Caller>.  The  sequence  tor  subsequent  references  to  <Datal  entry 
name>  is  shown  in  ^iqure  3. 

We  note  that  the  use  of  entry  names  within  data  imolies  that  the  data 
must  undergo  a  translation  and  have  a  symbolic  name  table  and  linkage  table. 
These  two  items  may  be  merged  into  one  structure  since  the  data  linkage  table 
consist  ot  a  header  which  (at  this  ooint)  only  contains  a  oointer  to  the  data 
symbolic  name  table. 
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3.  'Jnl  inking 

In  a  microcomputer  environment,  there  may  exist  a  limited  number  of  seg- 
ments available  tor  use  by  a  orocess  (2) .  To  prohibit  this  from  limiting  the 
size  ot  programs,  we  may  choose  to  unlink  objects  trom  an  address  space  in 
order  to  allow  the  dynamic  linking  ot  new  objects  to  the  orocess. 

I.  fundamentals  of  'Inlin'<ing 

Conceptually  unlinking  is  a  trivial  Process  but  may  include  Pitfalls 
which  must  be  taken  into  account.  To  unlink,  an  object  is  selected  for  remo- 
val, the  object's  entry  in  the  linkage  address  table  is  erased,  and  all  outgo- 
ing links  to  the  object  are  reset  to  their  presnapped  tormat.  This  implies 
two  major  points.  First,  any  data  required  to  reset  an  outgoing  link  must 
either  be  accessible  by  some  means  or  stored  in  the  outgoing  link  itself. 
Secondly,  we  must  be  able  to  find  each  snapped,  outgoing  link.  It  is  Proposed 
that  a  linked  list  of  outgoing  links  referring  to  an  object  be  formed  with  a 
Pointer  to  the  start  ot  this  linked  list  stored  in  the  object's  linkage  table 
header.  Thus,  in  the  trivial  case,  unlinking  an  object  consist  ot  erasing  the 
object's  entry  in  the  linkage  address  table,  resetting  each  outgoing  link  in 
the  object's  linked  list,  and  finally  deleting  the  object  and  its  linkage 
table  from  the  process  address  space. 

7.     Resolving  addressing  in  the  Combined  Linkage  Table 

Recall  that  we  said  there  were  pitfalls  involved  in  unlinking.  These 
arise  trom  how  an  object's  linkage  table  is  entered  in  a  process  address 


(7)  »is  an  example,  the  ZB000  microprocessor  [7]  with  one  Memory  Management 
'Init  allows  a  maximum  of  54  segments,  some  ot  which  must  be  assigned  to  the 
operating  system. 
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snace.  Observe  that  it  we  are  concerned  with  unlink inq,  there  are  not  ade- 
quate seqments  available  to  assiqn  each  linkaqe  table  a  unique  sequent  number. 
It  is  orooosed  that  in  such  an  environment ,  individual  lin'<aqe  tables  be  com- 
bined  into  a  sinqle  seqnent  which  we  will  call  the  combined  linkaqe  table. 

^ven  thouqh  the  combined  linkage  table  conserves  seqments,  it  creates 
addressinq  orobiems  which  must  be  taken  into  account.  It,  when  removinq  a 
deleted  object's  lin'oqe  table  trom  the  combined  lin'<aqe  table,  a  compaction 
ot  the  combined  linkaqe  table  is  oertormed,  some  remaininq  linkaqe  tables  may 
be  relocated. 

This  relocation  requires  the  following  three  addressinq  Problems  be 
resolved:  (1)  a  relocated  lin'<aqe  table  must  have  its  entrv  in  the  lin'<aqe 
address  table  undated,  (?)  outqoinq  links  which  transfer  control  to  an  incom- 
inq  link  in  a  relocated  linkaqe  table  must  be  undated,  (3)  nodes  ot  an 
(unlinker)  linked  list  nointinq  to  outqoinq  links  in  a  relocated  linkaqe  table 
must  be  undated. 

\  fourth  addressinq  nrobiem  which  must  be  resolved  involves  the  removed 
object's  linkaqe  table,  "ach  outqoinq  link  in  this  linkaqe  table  is  a  node  in 
a  linked  list  and  must  be  deleted  from  that  linked  list  nrior  to  removinq  the 
linkaqe  table  from  the  otocess  address  snace.  (We  note  that  a  doubly  linked 
or  circular  linked  list  ot  outqoinq  links  is  helotul  in  resolvinq  these  last 
two  addressing  Problems.) 

3.  Selectinq  an  Object  tor  Removal 

\  brief  comment  is  in  order  concerning  the  selection  ot  an  object  tor 
removal.  \  Procedure  cannot  be  unlinked  and  removed  trom  the  address  snace  if 
it  has  a  current  activation  record  since  this  would  break  the  integrity  of  the 
return  sequence  from  a  series  ot  one  or  more  orocedure  calls.  Therefore  a 
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mechanism  muse  be  deveiooed  to  test  tor  this  condition  orior  to  selectinq  an 
object  for  removal.  This  inolies,  tor  examole ,  that  the  initial  oroqram  can- 
not be  unlinked  since  it  is  always  either  executinq  or  in  the  return  sequence. 

IV.    SYSTEM  STjODq^T* 

We  should  now  like  to  briefly  discuss  operatinq  system  suooort  for 
dynamic  lin'<inq.  It  is  felt  that  the  capabilities  discussed  either  already 
exist  or  are  imolementable  in  most  microcomputers. 

\.     The  address  Soace  Manaqer 

The  address  space  manaqer  serves  as  an  interface  between  the  dynamic 
linker  and  the  ooeratinq  system.  It  will  call  on  ?ile  System  Manaqement  and 
(in  some  cases)  Memory  Manaqement  to  obtain  data  which  allows  it  to  convert 
the  symbolic  name  of  an  object  into  an  addressable  entity.  Havinq  done  this, 
the  address  soace  manaqer  will  save  this  data  in  a  table  (which  we  will  call 
the  orocess  reference  table)  to  or event  unnecessary  invocations  of  ooeratinq 
svstem  routines  for  subsequent  request  to  make  an  object  addressable  by  a  oro- 
cess. we  note  that  the  process  reference  table  is  a  'oer  orocess'  data  struc- 
ture and  each  object  entered  in  it  has  a  unique  set  of  attributes  (such  as 
seqment  number,  access  riqhts,  etc.)  with  resoect  to  that  process. 

When  oassed  a  symbolic  name,  the  address  soace  manaqer  must  be  able  to 
access  the  object  associated  with  that  symbolic  name  in  order  to  make  the 
object  addressable  by  the  orocess.  The  address  space  manaqer  will  return  to 
the  dynamic  linker  a  unique  orocess-identif ier  associated  with  that  object. 
This  object  identifier  has  been  assumed  to  be  the  seqment  number  assiqned  to 
the  object,  however  conceptually  all  an  object  identifier  must  do  is  to  allow 
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the  linker  (and  the  user  orocess)  to  address  the  object  in  some  fashion. 

"5.  Translator  Suooort 

Recall  that  the  linker,  us  inn;  some  to  mat  or  temolate,  must  build  a 
linkage  table  tor  each  object  when  that  object  is  entered  in  the  orocess 
address  soace.  The  existence  ot  this  tenolate  and  additionally,  the  existence 
of  the  symbolic  name  table,  imolv  that  the  translator  used  must  suooort 
dynamic  linking  by  not  onlv  translating  external  references  and  recognizing 
entry  names,  but  also  by  constructing  a  linkage  table  temolate  and  symbolic 
name  table  tor  the  translated  object.  \s  will  be  shown,  it  is  reasonable  to 
assume  that  a  translator  can  be  designed  (or  modified)  with  this  capability 
since,  in  ^enaral,  all  data  necessary  to  construct  these  two  items  is  either 
easily  computable  or  available  in  the  translator's  symbol  table. 

I.  The  Symbolic  Name  Table 

The  symbolic  name  table  (^iqure  4)  contains  an  entrv  tor  each  unique 
external  reference  and  entry  name.  In  addition,  the  linkage  table  offset  ot 
the  corresoonding  link  (i.e.,  outgoing  and  incoming  links)  for  each  symbolic 
name  table  entp/  should  be  stored  with  that  entry.  ,,re  note  that  this  is  man- 
datory for  entry  names;  however,  tor  external  references,  the  addition  ot  the 
(outgoing)  link  offset  is  only  convenient  since  it  removes  the  requirement  for 
the  linker  to  store  this  information. 

It  is  reasonable  to  as'<  where  the  symbolic  name  table  is  located  in  a 
orocess  address  soace.  Recall  that  tor  the  data  object  <bata> ,  we  have  sug- 
qested  that  bata.sym  be  aooended  to  Data. link.  (This  imolementation  allows 
<Oata>  to  be  based  at  offset  zero  and  to  grow  dynamically.)  T,'e  could  use  this 
solution  tor  a  orocedure  also;  however,  since  the  symbolic  name  table  does  not 
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chanqe,  a  seoarate  cooy  tor  each  orocess  is  not  needed.  \  reasonable  solution 
therefore  would  be  to  append  the  symbolic  name  table  no  the  end  ot  a  (oure) 
nrocedure's  object:  code. 

7.     The  Linkaqe  Table  Temoiate 

The  linkaqe  table  temolate  (^iqure  5)  should  reflect  the  exact:  format  of 
an  initialized  lin'<aqe  table  with  one  exception.  We  have  stated  that  the 
header  of  a  lin'oqe  table  contains  the  virtual  address  of  that  object's  sym- 
bolic name  table  yet  at  translation  tine  the  seqnent  number  of  the  svnboiic 
name  table  is  unknown.  Therefore,  we  must  construct  this  virtual  address  when 
the  lin'oqe  table  of  an  object  is  built.  If  the  svnboiic  name  cable  is  a  oart 
ot  the  object  code,  its  virtual  address  can  be  commuted  (qivan  we  know  the 
offset  ot  the  symbolic  name  table  in  the  object  code)  when  the  object's  seg- 
ment number  is  obtained  from  the  address  soace  manaqer.  It  the  svmbolic  name 
table  is  a  oart  of  the  lin'oqe  table,  we  can  obtain  the  lin'oqe  table  seqment 
number  via  the  lin'oqe  address  table. 

Notice  that  the  header  ot  ^iqure  5  includes  an  entry  reflectinq  the  size 
ot  the  lin'oqe  table.  This  represents  useful  information  it  an  uniinker  is 
imolemented  (bv  orovidinq  the  unl inker  with  the  size  ot  a  lin'oqe  table  to  be 
removed)  and  mav  orovide  useful  data  when  loadinq  a  linkaqe  table  in  a  orocess 
address  soace. 

By  buildinq  the  symbolic  name  table  first,  the  construction  ot  the  body 
ot  a  template  becomes  quite  trivial  tor  the  translator.  l,'e  note  that  there  is 
a  one-to-one  maooinq  between  entries  in  the  linkaqe  table  and  the  symbolic 
name  table.  Therefore  the  temolate  can  be  easily  constructed  bv  scanninq  the 
symbolic  name  table  and  initializinq  a  link  comoatible  with  each  oarticular 
symbolic  name  table  entry.   \s  each  link  is  initialized,  we  can  also  enter  its 
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link  offset  into  its  respective  symbolic  name  table  entry. 

It  is  reasonable  to  ask  where  in  a  svsten  the  linkaqe  table  temolate 
should  be  located.  It  is  suggested  that  unless  demand  oaqinq  is  available,  a 
separate  tile  tor  the  tenolate  be  created.  This  will  allow  the  construction 
ot  a  linkage  table  without  requirinq  that  the  tenolate  be  entered  in  a  orocess 
address  soace.  In  a  demand  oaqinq  environment,  the  linkage  table  tenolate  can 
be  a  oart  ot  the  object  code  and  once  it  has  been  utilized  to  construct  the 
linkage  table,  it  will  be  'oaged  out'  ot  main  memorv  since  it  will  not  be 
further  reterenced. 

g.  Process  Initialization 

Much  work  bv  Tanson  [3 ,91  has  been  devoted  to  orocess  initialization 
including  a  comolete  descriotion  ot  how  the  dynamic  linker  and  the  ooerating 
system  are  linked  in  a  multi-domain  environment.  Our  design  has  been  guided 
by  these  results.  It  should  be  noted  that  orocess  initialization  must  include 
the  orocess  reference  table  an^.  linkaqe  address  table.  With  resoect  to  a 
user's  orogram,  orocess  initialization  in  a  dynamic  linkinq  environment 
differs  only  in  that  the  linkaqe  table  for  the  user  oroqram  must  be  entered  in 
the  orocess  address  soace  and  the  linkaqe  oointer  initialized  orior  to  com- 
mencinq  oroqram  execution. 

V.   LIMXIMq  WITMO'JT  TRANSLATOR  S'J^OPT 

Havinq  imolied  that  translator  suooort  is  necessarv  to  realize  ^Vnamic 
linkinq,  we  would  like  to  summarize  an  imolementation  in  an  environment  where 
this  condition  does  not  hold;  the  imolementation  details  have  been  qiven  else- 
where [101 .   It  is  felt  that  a  linker  in  this  environment  should  meet  certain 
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fundamental  requirements,  ^irst,  we  would  like  to  use  the  same  dynamic  linker 
to  link  both  (translator)  supported  and  unsuooorted  objects  thus  requirinq 
only  one  linker  and  additionally  allowinq  a  orocess  to  utilize  both  object 
tyoes.  Mso,  we  do  not  wish  to  have  to  exolicitlv  declare  in  our  source  code 
an  external  object  to  be  suDoorted  or  unsuooorted  since,  if  that  object  is 
retranslated  with  a  type  chanqe  (e.q.  ,  unsuooorted  to  supported) ,  all  pro- 
cedures referrinq  to  that  object  would  have  to  be  retranslated  also.  (This 
imolies  that  the  linker  must  be  able  to  differentiate  between  supported  and 
unsuoDorted  objects.) 

\.     The  Interface  Module 

Recall  that  we  have  offered  an  exolicit  call  to  the  linker  in  a 
orocedure's  source  code  as  a  mechanism  for  linker  invocation  such  as 

CALL  <LINK>  (Target) 
In  this  examole,  ^WO  is  a  module  which  is  statically  linked  to  a  orocess 
and  serves  as  an   interface  between  the  orocess  and  the  dynamic  linker.  Con- 
ceotually,  <LIMT<>  must  carrv  our  those  functions  which,  in  a  (translator)  suo- 
oorted  system  involve  the  translator. 

B.  Linking  'Insuooorted  Objects 

T'.'e  will  now  investigate  the  steos  necessary  to  link  the  unsuooorted 
object  <Tarqet>  to  the  unsuooorted  orocedure  <Caller>  (^iqure  ^) . 

When  <LIMK>  is  called  it  will  enter  <Tarqet>  in  the  next  free  location 
in  Caller. sym  and  will  build  an  initialized  outqoinq  link  for  <Tarqet>  in 
Caller. link.  (If  <Tarqet*>  already  has  an  entry  in  Caller. svm,  it  also  has  a 
snaooed  link  and  all  that  is  required  is  to  execute  the  snaooed  link.)  <LIMK> 
will  then  load  <Tarqet>'s  parameters  into  the  system  accordinq  to  translator 
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conventions  and  execute  the  outgoing  link. 

'"hen  the  linker  identities  <Target>  as  unsuooorted,  it  will  cause  a 
block  ot  virtual  memory  to  he  allocated  to  serve  as  Target. lin'<  and  Target. syn 
(since  <Target>  has  neither  a  svmbolic  name  table  nor  linkage  table  tenolate) . 
hnce  Target. link  and  Target. syn  have  been  initialized,  the  linker  will  enter 
<Target>  as  the  only  entry  name  in  Target. sym  and  conolete  the  link  by  snao- 
oing  the  incoming  link  in  Target. link  (provided  <Target>  is  a  orocedure). 

n..     The  Interface  Linkage  Pointer 

We  can-^oir  exoect  that  an  unsuooorted  translator  will  know  that  the  link- 
age Dointer  hardyare  register  is  not  available  for  general  use  and  therefore 
must  assume  that  it  cannot  be  used  to  ooint  to  the  linkage  table  of  an  execut- 
ing unsupoorted  procedure.  We  therefore  prooose  that  an  interface  linkage 
oointer  be  established  (in  software)  by  <LIMT<>  to  duolicate  the  functions  of 
the  hardware  linkage  oointer. 

We  should  like  to  observe  two  imoortant  ooints.  ^irst,  the  incoming 
link  to  <Target>  must  set  the  interface  linkage  oointer  to  point  to 
Target. link  vice  the  hardware  linkage  oointer.  Second,  if  a  orocess  executes 
both  supported  and  unsupoorted  Procedures,  the  first  orocedure  executed  must 
be  supoorted  since  this  ensures  that  the  hardware  linkage  oointer  is  saved 
before  it  can  be  subject  to  general  use  bv  an  unsupoorted  orocedure. 

r).     The  disadvantages  of  'Jnsuooorted  dynamic  Linking 

There  are  tour  major  disadvantages  when  linking  in  an  unsuooorted 
environment.  To  begin  with,  subsequent  references  to  a  linked  object  will  be 
executed  much  slower  than  in  a  suooorted  system  since  housekeeoing  functions 
associated  with  linking  are  carried  out  by  software  routines  vice  object 
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(machine)  code.  Secondlv,  we  have  not  orooose^  a  mechanism  to  pass  external 
orocedures  to  subroutines  as  actual  oarameters.  ^  third  disadvantage  relates 
to  muitiole  entry  ooints.  Since  the  identification  ot"  enttv  names  and  their 
associated  entry  ooints  requires  translator  suooort,  an  unsupported  object  can 
onlv  be  accessed  at  one  entry  noint  (viz..  its  starting  location).  7\  tourth 
disadvantage  is  that  external  data  will  be  limited  to  a  based  variable  similar 
to  those  found  in  °L/T  or  °LAl  since  <LIMX>  can  only  return  to  the  noint  of 
call  a  oointer  to  the  external  data. 

VI.   HYr>JV^  IVPLICYTIOMS 

Having  discussed  the  design  ot  a  dynamic  lin'<er  to  execute  on  currently 
available  microorocessors,  we  would  li'<e  to  examine  hardware  features  which 
are  advantageous  in  a  dynamic  lin'<inq  environment.  The  hardware  features  dis- 
cussed can  be  classified  into  two  general  qrouos:  those  which  influence  the 
desiqn  of  the  dynamic  lin'<er  and  those  which  affect  the  svstem  performance  bv 
imorovinq  execution  sneed. 

\.     Hardware  features  '\tfectinq  Linking  besiqn 

We  will  discuss  four  hardware  features  which  affect  the  desiqn  ot  a 
dynamic  linker.  To  beqin  with,  the  abilitv  to  invoke  the  linker  via  a 
hardware  fault  ensures  that  a  comoletelv  qeneral  desiqn  can  be  implemented. 
Without  this  capability,  a  link  must  be  snanoed  when  external  data  is  oassed 
as  an  actual  oarameter  to  a  subroutine  (viz. ,  when  the  call  is  executed) , 
imolvinq  that  a  link  may  be  snaooed  orior  to  first  reference.  The  second 
desirable  hardware  feature  involves  the  capability  to  reference  external 
objects  via  indirect  addressing.   If  this  feature  exists,  snaooed  outgoing 
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links  are  sinoly  virtual  addresses  tor  indirect  addressing  instructions. 
(Multics  utilizes  indirect  addressinq  and  a  linkage  fault  on  indirection  in 
the  implementation  of  its  dynamic  linker  [61.) 

^  third  influencing  feature  involves  the  size  of  (hardware)  virtual 
memory.  ,,re  note  if  an  adequate  number  of  seqments  exist  (assuminq  each  seg- 
ment  is  of  reasonable  size) ,  it  may  not  be  necessary  to  imolement  an  unl inker. 
(We  can  always  conserve  seqment  numbers  by  combininq  smaller  objects  into  one 
seqment  orior  to  execution  and  reterencinq  each  object  via  an  entry  ooint.) 
The  final  feature  has  already  been  mentioned  and  is  the  ability  to  save  and 
restore  the  linkaqe  pointer  as  a  oart  of  the  microorocessor 's  C^LL  and  ^^ITJIN 
conventions. 

3.  Performance  Considerations 

Monq  the  lines  of  system  performance  we  will  discuss  two  hardware 
features:  the  hardware  re lo cat ability  of  code  and  hardware  segmentation. 
These  are  suooorted  bv  modern  microorocessors  such  as  the  Zilog  7T000  [71  and 
the  Intel  <WS  successor  [111  . 

With  respect  to  hardware  relocatability,  we  note  that  one  must  have 
relocatable  orocedure  seqments  to  implement  a  dynamic  linker  since  at  the 
start  of  oroqram  execution,  there  exist  no  bindinqs  between  procedures  and 
orocess  virtual  addresses.  Therefore,  the  more  efficiently  nrocedures  can  be 
relocated  (viz. ,  hardware  relocation) ,  the  better  system  performance  will  be. 

We  have  maintained  that  a  dynamic  linker  can  be  implemented  without 
hardware  seqmentation  as  lonq  as  individual  objects  can  be  referenced  as  logi- 
cal entities  (i.e.,  segments).  This  imolies  that  many  functions  intrinsic  to 
a  seqmented  system  must  be  available  in  a  dynamic  linkinq  environment.  It  is 
only  logical,  therefore,  to  conclude  that  it  is  advantageous  to  have  hardware 

2*> 


seqmentation.  In  particular,  the  in-core  sharinq  ot  objects  (e.q.  ,  oure  oro- 
cedures)  in  a  nultioroqramminq  environment  is  extremely  difficult  to  inclement 
without  the  suooort  ot  hardware  segmentation . 

VII.   C0MCL'JSIOMS 

We  have  oresented  a  desiqn  that  illustrates  the  teasibilitv  ot  dynamic 
linkinq  in  a  microcomputer  environment.  We  have  shown  that  there  are  only 
modest  demands  on  the  sumortinq  lanquaqe  translators,  ooeratinq  system,  and 
hardware.  On  the  other  hand,  the  desinn  is  not  in  contlict  with  the  more 
sophisticated,  state-ot-the-art  capabilities  that  can  be  exoected  tor  micro- 
comouters  ot  the  tuture.  furthermore,  the  oettormance  cost  is  quite  moderate: 
the  ooerations  tor  the  tirst  reference  are  essentially  those  ot  the  tradi- 
tional lin'<inq  loader.  Subsequently  we  require  about  three  additional 
instructions  oer  external  call  and  about  two  oer  external  data  reference. 
Thus,  we  conclude  that  it  is  Possible  and  oractical  to  include  the  substantial 
benefits  ot  dynamic  linkinq  in  the  set  ot  capabilities  for  oresent  and  tuture 
microcomputers. 
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